One more thing I noticed.

From the live logs of the machine, it seems that the repo got cloned again after I stopped then started the workspace.

Does this mean that the home folder of the user is not persisted? If so, we will need to make adjustments since it's very important that the git repo persists when a project is restarted.

One more thing I noticed.

From the live logs of the machine, it seems that the repo got cloned again after I stopped then started the workspace.

Does this mean that the home folder of the user is not persisted? If so, we will need to make adjustments since it's very important that the git repo persists when a project is restarted.

Machine / path is mounted to the volume but for stopped fly machine when you start the machine are restarted are completely reset to their original state so that they start clean on the next run https://fly.io/docs/machines/api/machines-resource/#start-a-machine

Machine / path is mounted to the volume but for stopped fly machine when you start the machine are restarted are completely reset to their original state so that they start clean on the next run https://fly.io/docs/machines/api/machines-resource/#start-a-machine

But volumes should be persistent. Also, you can not mount a volume to a directory that already exists in the image, that's why this "fails".

I suggest you mount the volume to Path: fmt.Sprintf("/home/%s/%s", project.User, project.Name) since that's where the project will be cloned. This should enable at least the git repo to be persisted.

I will discuss with the rest of the team how to address the issue where the rest of the machine is reset to the original state. We will have to make it clear in the README somewhere.

Machine / path is mounted to the volume but for stopped fly machine when you start the machine are restarted are completely reset to their original state so that they start clean on the next run https://fly.io/docs/machines/api/machines-resource/#start-a-machine

But volumes should be persistent. Also, you can not mount a volume to a directory that already exists in the image, that's why this "fails".

I suggest you mount the volume to Path: fmt.Sprintf("/home/%s/%s", project.User, project.Name) since that's where the project will be cloned. This should enable at least the git repo to be persisted.

I will discuss with the rest of the team how to address the issue where the rest of the machine is reset to the original state. We will have to make it clear in the README somewhere.

I have updated the mounted path to /root, which now makes the project persist.

2024-05-29T17:56:01.506 app[e78432e6f23e83] jnb [info] Installing server to /usr/local/bin

2024-05-29T17:56:01.549 app[e78432e6f23e83] jnb [info] Starting Daytona Agent

2024-05-29T17:56:03.803 app[e78432e6f23e83] jnb [info] Repository already exists. Skipping clone...

2024-05-29T17:56:03.804 app[e78432e6f23e83] jnb [info] Running post start commands...

2024-05-29T17:56:03.804 app[e78432e6f23e83] jnb [info] Running command: sudo dockerd

2024-05-29T17:56:03.804 app[e78432e6f23e83] jnb [info] Starting ssh server on port 2222...

@bcmmbaga the code looks great now but I'm encountering weird errors again.

Try to create a couple of workspaces in a row. I got this error on the third one:

Seems there's still some race conditions going on.

@bcmmbaga the code looks great now but I'm encountering weird errors again.

Try to create a couple of workspaces in a row. I got this error on the third one:

Seems there's still some race conditions going on.

I will attempt to reproduce this issue. In the meantime, could you check if an app with this name exists on the Fly dashboard and confirm its status?

@bcmmbaga the code looks great now but I'm encountering weird errors again.
Try to create a couple of workspaces in a row. I got this error on the third one:
Seems there's still some race conditions going on.

I will attempt to reproduce this issue. In the meantime, could you check if an app with this name exists on the Fly dashboard and confirm its status?

The app is always present but remains in Pending state.

@bcmmbaga the code looks great now but I'm encountering weird errors again.
Try to create a couple of workspaces in a row. I got this error on the third one:
Seems there's still some race conditions going on.

I will attempt to reproduce this issue. In the meantime, could you check if an app with this name exists on the Fly dashboard and confirm its status?

The app is always present but remains in Pending state.

I can confirm it is not a race error, as the error indicates that the machine is included in response from Fly.io. This seems to be related to Fly.io's end, as I have seen similar issues reported by other users when deploying: https://community.fly.io/t/app-stuck-on-pending/9550/13, https://community.fly.io/t/app-stuck-in-pending-state/4680

I can confirm it is not a race error, as the error indicates that the machine is included in response from Fly.io. This seems to be related to Fly.io's end, as I have seen similar issues reported by other users when deploying: https://community.fly.io/t/app-stuck-on-pending/9550/13, https://community.fly.io/t/app-stuck-in-pending-state/4680

Is it possible to add some sort of check if the app is ready? I can see you implemented WaitForApp but should we check the state of the app as well?

I can confirm it is not a race error, as the error indicates that the machine is included in response from Fly.io. This seems to be related to Fly.io's end, as I have seen similar issues reported by other users when deploying: https://community.fly.io/t/app-stuck-on-pending/9550/13, https://community.fly.io/t/app-stuck-in-pending-state/4680

Is it possible to add some sort of check if the app is ready? I can see you implemented WaitForApp but should we check the state of the app as well?

WaitForApp covers this scenario because an app in a pending state won't be returned in the API response.

WaitForApp covers this scenario because an app in a pending state won't be returned in the API response.

From what I can see, the error is generated from this function:

Should we implement waiting for the app before this?

WaitForApp covers this scenario because an app in a pending state won't be returned in the API response.

From what I can see, the error is generated from this function:

Should we implement waiting for the app before this?

We can implement this, but we might still encounter the error because the initial check also waits for the app. Since it passed, it means the app was ready, which is why the volume and machine were created. However, just before starting, the app went into a pending state again, making it unrecoverable. In this case, we could experience a timeout while waiting for the app to be ready

We can implement this, but we might still encounter the error because the initial check also waits for the app. Since it passed, it means the app was ready, which is why the volume and machine were created. However, just before starting, the app went into a pending state again, making it unrecoverable. In this case, we could experience a timeout while waiting for the app to be ready

I suggest that we check the app status again and wait for the appropriate state. If the state isn't reach in 2 minutes, we can notify the user that there was a problem with their app.